Use hashtable output in GetSafePathsToAllow.ps1 #7
Conversation
…d "RuleCollection" properties
|
|
|
User profile directories are never safe directories |
Very true. Unfortunately there are still many software installed by users (e.g. Anaconda) where most files are not signed, and thus, would require lots of hash rules for white listing, and this for all possible versions. In an environment like ours (university) where not all software are managed by IT, and users should not be restricted in software (and versions) they want to use, this would be a nightmare to manage. Off course we want that software is installed in safe paths as much as possible, but it's not possible for all. So for some software we have to make a trade off between manageability/usability and security. Perhaps we can emphasize in the documentation that adding user profile directories is inherently unsafe. Would this be acceptable? |
|
there is a long list of software that installs in user profile: gotomeeting, zoom, webex, ... |
|
"AaronLocker" and its documentation distinguish between "safe" and "unsafe" paths. The former are directories within which only admins can create, modify, or delete content. (E.g., "Program Files" and its subdirectories are safe by default.) If non-admins can create, modify, or delete content, the directory is considered "unsafe." User profile directories are one example. You can use Path rules only for "safe" directories; allowing execution of files in "unsafe" paths requires Publisher or Hash rules, depending on whether the files are signed. Unsigned files in unsafe directories are going to be a pain to manage if they are ever updated. That's a given no matter how you do it. And yes, there are lots of apps (IMO too many) that install to user profile directories. My point in my initial, way-too-brief comment was that the proposed edits for handling of GetSafePathsToAllow.ps1 included a lot of code for string substitution for user profile directories, to which GetSafePathsToAllow should never apply. I'll have to double-check also, but I'm pretty sure you can't use USERPROFILE, APPDATA, or LOCALAPPDATA environment variables in AppLocker rules. I do those substitutions in the reporting end to get "generic" paths when events are reported. |
I did get your point 😃 .
I know, that's why paths with Would you prefer everything related to profile paths to be removed? |
These are usually the easy ones, they often are signed. But software like R, Python, Anaconda, Julia, LateX,... is hell with lots of unsigned Exe/Dll and you don't want these to be installed as admin in Program Files because users should be able to easily update the software and install plugins without having admin rights. Visual Studio Code is another example where it's preferred to install the software not as admin, but that one is nicely signed. So that is an easy one too 😄 |
|
You'll never want to create a Path rule for anything under %OSDRIVE%\Users*. Ever. If you want to allow non-admins to download/update and execute unsigned files, you cannot implement whitelisting in a meaningful way. For that matter, it's really hard to implement whitelisting for developers because they need to create executable content that has never existed before and be able to test it. |
I do not agree on that. You can whitelist an agreed upon path that developers can use to compile and test their executable content. Yes this folder will induce a risk, but the risk is smaller than doing no whitelisting at all. As such it is at least possible to block other executable content that may be downloaded and executed unintentionally by the user, what our first concern is. Anyway, I just wanted to contribute the changes we made to be able to use hashtables in GetSafePathsToAllow.ps1, something that was also marked as TODO by you. The least what I can do in return for the great work you've shared. |
|
Re whitelisting for developers - you're correct, to a point. I do exactly that on my own machine - I have a small number of paths that I can write to and in which I allow execution. Whitelisting in cases like this requires total buy-in from the interactive user. If you have a user who chafes at security policies and wants to bypass them, there's nothing you can do. For developers you pretty much need to make that compromise, unless you can take other steps such as ensuring that their dev/test machines are on air-gapped machines and making it really hard through other means (e.g., no external drives) to introduce bad things. For anyone else, you have to rely on their naivete that bypasses are available (security by obscurity). |
Use hashtable output supporting "label" and "RuleCollection" properties so that path rules have more descriptive names, and can be applied to specific rule collections.